With few exceptions, data groups must be defined in a device template file in order for them to be available for use on a remote device. Which data groups are defined by a device template file depends on protocol, device type, and unique configuration.
CygNet distributes sample device template files for its EIEs, each of which typically serves one or more hardware models along with applicable firmware. Therefore, the data groups described below are only those data groups defined by CygNet in sample device template file(s). Your template(s) might not include some of the data groups described below. Device template files exist to enable users to customize device configurations; however, CygNet is not responsible for changes made by users.
For information about data group definitions and device template files, see Device Template Files.
For more information about data group dependencies, see Data Group Dependencies.
Note: Many Eagle data groups include a notable property setting on the Data Group Properties dialog box that enables an ordinalized data group to be associated with a different process type instance number. The setting is called Process Type Instance. For more information, see also Overriding Process Type Instances.
Browse by letter: A D F G H M P S V
| Data Group Type | Usage Notes |
|---|---|
|
"Alarm Data" retrieves alarm configuration for an associated field device. This data group must be instantiated before any other data group that depends on alarms can be polled. For example, instantiate this data group before polling "FMS Alarms". An Eagle alarm application contains a maximum of four alarm types. If your system needs more than four types, additional alarm programs must be added to accommodate the additional types. All alarm application instances are consolidated into a single AlarmData data group. In the data view of the AlarmData data group, check Show all, then locate the Alarm PPSSII column. This value contains the process configuration for alarms; see the "Process Configuration" (ProcessCfg) data group for the scheme that explains what these values mean in your configuration. By default, this data group is set to retain 40 days of transaction history. This default setting is in place to satisfy the requirements of historical data collection in CygNet Measurement. |
|
|
AlmStat |
"Alarm Status" uses a ProcessType.Section.Item scheme to map data group elements to items on the field device. This data group can be user-modified. |
|
Audit |
"Audit Trail" is used to retrieve audit data for a number of predefined entry types. It uses proprietary message type 16; the audit-trail reset uses message type 26. The data group cannot be modified. By default, this data group is set to retain 40 days of transaction history. This default setting is in place to satisfy the requirements of historical data collection in CygNet Measurement. Note: When changing the transaction retention settings for this data group type, you will be prompted to confirm the change. CygNet recommends that data be retained for at least 40 days to be available for CygNet Measurement. Either change the transaction retention settings to retain more data, or accept the settings, which may cause CygNet to lose data that cannot be retrieved again. See the UIS command component parameters Seq and Reset. |
|
"Date/Time" |
|
|
"FMS Alarms" is defined in the device template file. Dependencies:
"Alarm Data" (AlarmData) and "History Alarm" (HistAlarm) must be instantiated before this data group can be polled. |
|
|
FmsConfig |
"FMS Configuration" is defined in the device template file. "FMS Configuration" must be retrieved before polling other FMS data groups of the same ordinal. Dependencies:
|
|
"Fms Events" Dependencies:
|
|
|
"FMS Daily History" Dependencies:
|
|
|
"FMS Hourly History" Dependencies:
|
|
|
"Gas Quality" uses a ProcessType.Section.Item scheme to map data group elements to items on the field device. This data group can be user-modified. |
|
|
"History Alarm" is a collection of historical alarm records. It consolidates historical alarm information for all alarm types configured for the associated field device. The data group property Process Type Instance must be set to the history application instance configured to hold alarm history on the associated field device. By default, this data group is set to retain 40 days of transaction history. This default setting is in place to satisfy the requirements of historical data collection in CygNet Measurement. |
|
|
HistCfg8 |
"History (8) Config" retrieves configuration information used to construct a "History (8)" data group. This information comes from the station configuration used by the connected field device. The "History (8) Config" data group and the "History (8) Support" data group do not need to be instantiated in order for a "History (8)" data group to work. You are only required to poll the "History (8)" data group. The ordinal number of this history data group must also match the applicable instance number as displayed in the "Process Configuration" data group. The instance number represents an instance or occurrence of a process type number. For example, if you want history from process type 34 and that type is instance 4, make the history data group collection ordinal 4. Some of the Current Value values returned for this data group contain pointers to historical data. The format of such pointers is PPSSII where up to 3 digits can be used to stand for PP, up to 2 digits can be used to stand for SS, and up to two digits can be used to stand for II (for example, ###/##/##). |
|
HistCfg16 |
"History (16) Config" retrieves configuration information used to construct a "History (16)" data group. This information comes from the station configuration used by the connected field device. The "History (16) Config" data group and the "History (16) Support" data group do not need to be instantiated in order for a "History (16)" data group to work. You are only required to poll the "History (16)" data group. The ordinal number of this history data group must also match the applicable instance number as displayed in the "Process Configuration" data group. The instance number represents an instance or occurrence of a process type number. For example, if you want history from process type 34 and that type is instance 4, make the history data group collection ordinal 4. Some of the Current Value values returned for this data group contain pointers to historical data. The format of such pointers is PPSSII where up to 3 digits can be used to stand for PP, up to 2 digits can be used to stand for SS, and up to two digits can be used to stand for II (for example, ###/##/##). |
|
"History Daily (Orifice)" |
|
|
"History Hourly (Orifice)" |
|
|
"History (8)" enables the display of historicized process variable data. This data group can include up to 8 process variables. There are 4 history types possible; confirm that the type you want to use is currently supported by CygNet:
The ordinal number of this history data group must also match the applicable instance number as displayed in the "Process Configuration" data group. The instance number represents an instance or occurrence of a process type number. For example, if you want history from process type 34 and that type is instance 4, make the history data group collection ordinal 4. Both the "History (8) Config" data group and the "History (8) Support" data group must be instantiated in order for a "History (8)" data group to work. However, you are only required to poll the "History (8)" data group. These data groups must have the same ordinal number. Max Records to Read specifies the maximum possible number of records to read in a single transaction. The highest value possible for Max Records to Read is 960 or the size of the field device buffer if it is less than 960. Subsequent transactions might be required to retrieve all required data. If not specified, all remaining records will be read. When used with Get Data by Index, the Max Records to Read value is relative to the starting record index and the total number of indexed records available. The quantity and indexes of records retrieved varies accordingly. To view the complete history data group as assembled by CygNet, use the View Dev/Dg Specific Info option in the CygNet DDS Viewer utility (DdsViewer.exe). |
|
|
"History (16)" enables the display of historicized process variable data. This data group can include up to 16 process variables. There are 4 history types possible; confirm that the type you want to use is currently supported by CygNet:
The ordinal number of this history data group must also match the applicable instance number as displayed in the "Process Configuration" data group. The instance number represents an instance or occurrence of a process type number. For example, if you want history from process type 34 and that type is instance 4, make the history data group collection ordinal 4. Both the "History (16) Config" data group and the "History (16) Support" data group must be instantiated in order for a "History (16)" data group to work. However, you are only required to poll the "History (16)" data group. This collection of data groups must have the same ordinal number. Max Records to Read specifies the maximum possible number of records to read in a single transaction. The highest value possible for Max Records to Read is 960 or the size of the field device buffer if it is less than 960. Subsequent transactions might be required to retrieve all required data. If not specified, all remaining records will be read. When used with Get Data by Index, the Max Records to Read value is relative to the starting record index and the total number of indexed records available. The quantity and indexes of records retrieved varies accordingly. To view the complete history data group as assembled by CygNet, use the View Dev/Dg Specific Info option in the CygNet DDS Viewer utility (DdsViewer.exe). |
|
|
HistSup8 |
"History (8) Support" retrieves a subset of configuration values that are used each time a "History (8)" data group with the same ordinal is polled. Its primary function is to retrieve the current history record number (in other words, the index) so the "History (8)" data group retrieves the correct collection of historical data. |
|
HistSup16 |
"History (16) Support" retrieves a subset of configuration values that are used each time a "History (16)" data group with the same ordinal is polled. Its primary function is to retrieve the current history record number (in other words, the index) so the "History (16)" data group retrieves the correct collection of historical data. |
|
"Orifice Meter Config" uses a ProcessType.Section.Item scheme to map data group elements to items on the field device. This data group can be user-modified. |
|
|
MtrCfgT |
"Turbine Meter Config" uses a ProcessType.Section.Item scheme to map data group elements to items on the field device. This data group can be user-modified. |
|
MtrDataO |
"Orifice Meter Data" uses a ProcessType.Section.Item scheme to map data group elements to items on the field device. This data group can be user-modified. |
|
MtrDataT |
"Turbine Meter Data" uses a ProcessType.Section.Item scheme to map data group elements to items on the field device. This data group can be user-modified. |
|
"Process Configuration" enables you to retrieve the field device process configuration. Process types are displayed according to the order in which they are loaded to nonvolatile memory on the field device. This data group must be polled before any other data group that uses a ProcessType.Section.Item scheme can be polled. The order in which process types in an application are loaded is reflected by a numeric ID called the Process Number. Process numbers are sequential. Process numbers and process types are not the same thing. A single process type can be used in numerous places in nonvolatile memory, so one process type might have several different process numbers associated with it. In CygNet, instance numbers are applied to all processes; instance numbers are incremented to indicate that a process type appears in more than one memory location. |
|
|
"Single Item" enables you to communicate with a single item. What process number corresponds to which process type varies by configuration. One way to get the required ProcessNumber.Section.Item parameters is to poll and look at the "Process Configuration" data group. Another way is to use the ProcessNumber.Section.Item field to create an item pointer to retrieve a process number's type. This helps you to confirm the process type before continuing. Any item retrieved for that process number is applicable to the retrieved process type. For example, poll 01.01.02 to retrieve the process type configured for the process number 01. Imagine the process type returned is 45. All section.item combinations for process number 01 (i.e., 01.xx.yy) would be applicable to process type 45. |
|
|
Station |
"Station" retrieves the station name assigned to the connected field device. The "Station" data group uses proprietary message type 42. It can not be modified. |
|
System |
"System Information" |
|
"Version" uses proprietary message type 19. It can not be modified. |